Systems and methods for providing information about features of a route

ABSTRACT

Systems and methods are disclosed for providing information about features of a route. In one implementation, a computer-implemented method includes operations performed by at least one processor. The method includes receiving, from a first device, input by a first user, the input including an observed condition of at least one feature associated with a first route, and determining, based on the input and condition information received from sources other than the first user, a status of the at least one feature associated with the first route. The method further includes receiving, from a second device of a second user, a request for a second route, the second route including a plurality of features including the at least one feature associated with the first route. In addition, the method includes providing, to the second device, information about the second route and the status of the at least one feature.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. Provisional Application Ser.No. 60/884,695, filed on Jan. 12, 2007 and U.S. Provisional ApplicationSer. No. 60/947,827, filed on Jul. 3, 2007, each of which areincorporated by reference in their entirety.

TECHNICAL FIELD

This disclosure relates to condition information for computer-generatedmapping.

BACKGROUND

Computer devices may be used to generate or provide mapping informationto users. For example, systems may enable communication with a host torequest specific maps or routes which may determine an appropriate routeand send the route to a portable computer device or desktop computer.

SUMMARY

In one general aspect, a method for enabling a user to perceive map orroute information based on previous user input of conditions of featuresincludes receiving a request for a first route from a first user anddetermining the first route having one or more features associatedtherewith. The method also includes enabling a first user to perceive afirst route and receiving condition information to be used as a basisfor accessing the one or more features associated with the first routefrom the first user. The method further includes using the conditioninformation received from the first user and condition informationreceived from sources other than the first user to determine one or morestatuses of the one or more features and storing the determined one ormore statuses. Moreover, the method includes receiving a request for asecond route from a second user and determining the second route asincluding the one or more features associated with the first route. Inaddition, the method includes accessing the stored one or more statusesof the one or more features and enabling the second user to perceive thesecond route and the accessed one or more statuses of the one or morefeatures.

In another general aspect, a method for enabling a user to perceive mapor route information including a status includes enabling a first userto perceive one or more features of a map and receiving conditioninformation that reflects a condition perceived by the first user asexisting relative to the one or more features based on input from thefirst user. The method also includes receiving a request for a routefrom a second user and determining a response to the request for theroute including the route based on the condition information receivedfrom the first user related to the one or more features. Also, themethod includes enabling the second user to perceive the route based onreceipt of the response.

Implementations may include one or more additional features. Forexample, determining the response to the request for the route mayinclude determining the route and a status of one or more featuresassociated with the route, and enabling the second user to perceive theroute based on receipt of the response may include enabling the seconduser to perceive the route and the status of the one or more features.Receiving condition information may include receiving informationreflective of a prediction of an amount of traffic that will traverse aportion of a road or an intersection at a future time. Also, receivingcondition information may include receiving information reflective of anamount of traffic currently traversing a portion of a road or anintersection. Further, receiving condition information may includereceiving an update from the first user of an amount of trafficcurrently traversing a portion of a road or an intersection previouslycommunicated to the first user.

Also, in the method, enabling the second user to perceive the route andthe status of the one or more features may include enabling the user toperceive an indication of the source of the received conditioninformation used in determining the response to the request for theroute. In addition, enabling the second user to perceive the route andthe status of the one or more features may include enabling the user toperceive an indication of the amount of the received conditioninformation used in determining the response to the request for theroute. Further, enabling the second user to perceive the route and thestatus of the one or more so features may include enabling the user toperceive one or more icons as associated with one or more features, eachicon being associated with a particular status. Moreover, enabling afirst user to perceive the map may include enabling a user to perceive afirst route including a first feature, and receiving the conditioninformation may include receiving condition information associated withthe first feature.

Further, in the method, determining the response to the request for theroute may include determining a status of the first feature in responseto and after receiving the request for the route, and enabling thesecond user to perceive the route may include enabling the second userto perceive the route including the first feature and the determinedstatus of the first feature. Determining a status of the first featurein response to and after receiving the request for the route may includedetermining that the route includes the first feature, and using thereceived condition information to determine a status of the firstfeature based on the determination that the route includes the firstfeature. Also, determining the response to the request for the route mayinclude determining a status of the first feature before receiving therequest for the route and accessing the determined status of the firstfeature in response to receiving the request for the route and enablingthe second user to perceive the route may include enabling the seconduser to perceive the route including the first feature and thedetermined status of the first feature.

Additionally, in the method, determining a status of the first featurebefore receiving the request for the route may include using thereceived condition information to determine a status of the firstfeature and storing the determined status of the first feature. Themethod may also include determining that the route includes the firstfeature and accessing the stored status of first feature based on thedetermination that the route includes the first feature. Moreover, themethod may also include determining whether the first user should beenabled to perceive the stored status of the first feature. Determiningwhether the first user should be enabled to perceive the stored statusof the first feature may include use of user-specific rules. Inaddition, the method may include enabling the first user to specifyoptions which affect the user-specific rules. Determining the responseto the request for the route may include determining whether to includethe one or more features within the route based on the conditioninformation received from the first user.

Implementation may include methods, systems, and devices with similarfeatures. Also, implementations of the desired techniques may includehardware or computer software on a computer accessible medium. Thedetails of one or more implementations are set forth in the accompanyingdrawings and the description below. Other features will be apparent fromthe description and drawings, and the claims.

DESCRIPTION OF DRAWINGS

FIG. 1 is a flow chart illustrating an example of a process for sendinga route including condition information.

FIG. 2 is a block diagram illustrating an example of a system fordelivering mapping information including condition information.

FIG. 3 is a block diagram illustrating an example of a client device forreceiving condition information from a user and a host.

FIG. 4 is a flow chart illustrating an example of a process forreceiving condition information.

FIGS. 5A-5C are exemplary graphical user interfaces including conditioninformation.

FIG. 6 is a flow chart illustrating an example of a process for enablinga user to perceive a route determined based on condition information.

FIGS. 7A-7B are additional exemplary graphical user interfaces includingcondition information.

FIGS. 8A-8B are flow charts illustrating examples of processes thataccess condition information after determining features in a route.

FIGS. 9A-9B are flow charts illustrating examples of processes thataccess condition information before determining features in a route.

Like reference symbols in the various drawings indicate like features.

DETAILED DESCRIPTION

In one particular implementation, a mapping system is configured todeliver map and/or route information to a large number of subscribers,the map and/or route information includes status information (e.g.,traffic status, weather status, or information regarding a prediction ofstatus) for various portions of the map/route. The mapping system isconfigured to determine the status information from conditioninformation received from one or more sources, including from subscriberinput of condition information reflective of the conditions of portionsof the map/route witnessed by the subscribers while traveling. Themapping system enables the subscribers to select portions of themap/route (e.g., highway 66 between exit 55 and 77) to specify conditioninformation for the selected portions of the map/route. The subscribersmay make the specification, for example, at home using a desktopcomputer or when traversing the map using a routing device. Conditioninformation includes indications of one or more specific conditions(e.g., “heavy traffic” or “rush hour typically from 4-6 pm”) of aportion or feature of the map or route.

In one implementation, the condition information may be entered by auser currently experiencing the condition while traversing the portionof feature of the map or route and may be sent to a host. In anotherimplementation, the condition information may be entered as a predictionof general trends and not by a user experiencing the condition. Themapping system uses the subscriber-inputted condition information andoptionally condition information from other sources to determine anddisplay to users a status for the corresponding portions of themap/route (e.g., congestion delays on highway 66 between exit 55 andexit 77). In this manner, the mapping system is able to leveragesubscriber input to provide and dynamically update status informationdisplayed to subscribers in routes/maps generated by the mapping system.Moreover, the mapping system may be configured to use such statusinformation for determining an optimal route between an originationaddress and a destination address in response to a subscriber requestfor directions.

More specifically, a mapping or direction-finding service may include amechanism by which a user (i.e., a subscriber) may select a feature of amap or a route displayed in, for example, a graphical user interface(GUI). A feature of a map or a route may be a portion or a region of amap of a geographic area or, additionally or alternatively, may be astep in a series of directions (e.g., a step in a route) offered by adirection finding service for traveling across a geographic area.Examples of features include: a road, a portion of a road, anintersection, an on-ramp, an off-ramp, a city, a specific location orregion (e.g., Dulles Corridor and the BackBay Area), or other featuresor points of interest typically illustrated in or designated by a map.The system may enable the user to select or input condition informationto be associated with the selected feature. In one implementation, theuser selects a road and inputs condition information reflecting thecurrent condition of the road. For example, the condition informationmay be selected by the user from among multiple predetermined conditionoptions including “light traffic,” a “traffic jam,” or a “trafficaccident.” The condition information may be inputted by a user, forexample, by inputting a freeform text string or, if selecting from amongpredetermined condition options, by selecting one or more displayedtextual or graphical icons or tags corresponding to differentpredetermined condition options presented in a GUI.

By enabling user input of condition information, the potential pool ofinformation for a system to determine statuses of features is increasedbeyond that of available automated systems to possibly include anyvehicle along a road. Also, users are enabled to update or correctinformation that is wrong or outdated. For example, if a user of asystem stuck in traffic receives a status that the road is traffic free,a user may be enabled to correct the erroneous status through inputtingcondition information of “traffic deadlock.” This input may update theuser's GUI as well as facilitate the transmission of correct statuses toother users. Also, user's of condition information may use “buddy lists”(e.g., of AOL Instant Messenger) or other user groups to share conditioninformation only with a subset of users. For example, a group of friendsmay wish to receive statuses based only on condition informationreceived from the group of friends.

The mapping system uses condition information inputted by users and/orreceived from other sources (e.g., traffic reports received from a datafeed) to determine statuses of features. A status of a feature is thecondition, state, or a prediction or general trend of the condition orstate of a feature. The feature may be accepted by the mapping systemfor display to one or more users and determined by the mapping system byapplying predetermined rules to received condition information. A statusof a feature may be displayed, for example, in a displayed map and/or adisplayed set of directions as text, a graphical icon, and/or agraphical tag that is in close proximity to, references, or is otherwiseassociated with the feature.

The rules that the mapping system applies to received conditioninformation to determine status information of features (i.e., statusgeneration rules) may be global and/or may be user-specific. Globalrules determine statuses of features for all or for a subset of users inthe subscriber base while user-specific rules determine statuses offeatures for only a single user. User-specific rules are typicallyspecified by or for a single user. If global and/or user-specific rulesconflict, the system may select which rules govern based on preferencesof individual users and/or based on prioritization schemes set forth bythe system (e.g., user-specific rules specified by a user always takeprecedence over global rules). Alternatively or additionally, multiplestatuses may be shown, each corresponding to a different rule applicableto the feature (e.g., a status determined from a user-specific rule maybe designated by “U” while a status determined from a global rule thatis different from that designated by the user-specific rule may bedesignated by “G”).

An exemplary user-specific status generation rule may be: if I submit acondition for a feature, the status assigned to the feature anddisplayed to me in a route or map should always match the condition ofthe feature I submitted. To illustrate, a particular user may submitcondition information indicating that a road has “heavy traffic.” Themapping system may receive that condition information and may assign astatus of “heavy traffic” to that road and may display that status whendisplaying a map or a route that includes that road to the particularuser. The status of “heavy traffic”, however, may not be assigned tothat road or displayed for that road in maps or routes displayed by themapping system to other users. The status generation rule, therefore, isuser-specific.

Another example of a user specific status generation rule may be: if oneof my buddies on my buddy list submits a condition for a feature, thestatus assigned to the feature and displayed to me should match thecondition of the feature submitted by my buddy. To illustrate, if mybuddy submits (manually or otherwise) condition information indicatingheavy traffic on road X, I perceive the same, irrespective of ornotwithstanding (and potentially in addition to) condition informationfor that road that is submitted by other users or buddies of mine. Thiscould be applied to other classes or groups of users that I specify(e.g., people I know, users on a buddy list of an Instant Messageprogram, users associated with another online group, users associatedwith another Internet social network, etc.).

Moreover, an exemplary global status generation rule may be: if morethan ten users submit condition information within a predeterminedwindow of time (e.g., 5 minutes) indicating the same condition (e.g.,“heavy traffic”) for a feature (e.g., road), then the status of thefeature should be changed to match that condition for all (or for apredetermined subset) users. This threshold number of ten users maychange depending on how many users are currently accessing and viewing amap/route that includes that feature and/or the number of users that aredetermined to be traversing that feature via location detection duringthe window of time. Alternatively or additionally, a percentage of usersrather than a threshold number may be used. For example, if more than 5%of users viewing the road in a map/route or traversing the road within afive minute interval submit condition information indicating heavytraffic, then assign the road the status of “heavy traffic” for allusers. Other rules may generate statuses for features that are acombination of the different conditions received from users and fromother sources. For example, if five users submit that a road has “lighttraffic” and five users submit that a road has “heavy traffic,” than anincluded status generation rule in the mapping system may assign thestatus “moderate traffic” to the road. Notably, the rules discussedabove and below may be default rules and/or may be manually establishedor overridden through, for example, selection of user-selected optionsas described below.

Referring to FIG. 1, a flow chart illustrates an example of a process100 for sending a route including status information. In the process100, a host receives condition information from a first user and arequest for a route from a second user. In response, the host calculatesand delivers the route to the user and may also deliver statuses of oneor more features of the route to the second user.

The process 100 begins when a first user is enabled to perceive a firstroute (110). The first route may be sent in response to receipt of arequest for the route from the first user. Also, the first route mayinclude one or more features, such as, roads, portions of roads,intersections, on-ramps or off-ramps, points of interest, cities, orother specific locations or regions.

Condition information of one or more features associated with the firstroute is received from the first user (120). Specifically, afterreceiving the first route, the first user's client system may render theroute and may enable the user to indicate a condition of one or morefeatures on the route. The condition may indicate a current condition oftraffic, traffic movement, congestion or delay, weather, detour or roadblockage, or other conditions. The condition information may be storedand accessed in response to other requests. A request for a second routeis received from a second user (130). The second user may be a differentindividual than the first user and may be accessing a different clientsystem than the first user's client system. Also, the second route mayinclude a different origin and destination than the first route.

A second route and a status of one more features associated with thesecond route are determined using the received condition information(140). In one implementation, after receiving the request, the secondroute is initially determined. Thereafter, using the determined secondroute, a stored status or condition information for features in thedetermined second route is accessed. In another implementation, afterreceiving the request for a second route, stored condition informationor statuses are accessed. Thereafter, the second route is determinedusing the status or condition information.

The second user is enabled to perceive the second route and the statusof the one more features associated with the second route (150). In oneimplementation, the status sent to the second user is the same as thecondition information received from the first user. Alternatively, inanother implementation, a different status is sent to the second user,where the different status is generalized, weighed, or averaged based onreceipt (or lack thereof) of condition information from various users.For example, if the first user's condition information specifies “heavytraffic” for a feature, and another user's condition informationspecifies “light traffic” for the same feature, a status of “moderatetraffic” may be sent to the second user.

Referring to FIG. 2, a system 200 for delivering mapping informationincluding status information includes a host 210, communication networks220, client devices 230, and information providers 240. In the system200, the host 210 receives requests for mapping information and statusinformation from the client devices 230 through the communicationnetworks 220. The host also may receive condition information from theinformation providers 240 through the communication networks 220. Thehost 210 uses the received condition information when determining and/ordelivering mapping information and status information to the clientdevices 230.

Each of the client devices 230, the information providers 240, and thehost 210 may be implemented by, for example, a general-purpose computercapable of responding to and executing instructions in a defined manner,a personal computer, a special-purpose computer, a workstation, aserver, a device, a component, other equipment or some combinationthereof capable of responding to and executing instructions. The clientdevices 230 and the information providers 240 may be configured toreceive instructions from, for example, a software application, aprogram, a piece of code, a device, a computer, a computer system, or acombination thereof, which independently or collectively directoperations, as described herein. The instructions may be embodiedpermanently or temporarily in any type of machine, component, equipment,storage medium, or propagated signal that is capable of being deliveredto the client devices 230 or the host 210.

The client devices 230 and the information providers 240 may include oneor more devices capable of accessing, sending, or receiving content fromthe host 210. The client devices 230 may include a general-purposecomputer (e.g., a personal computer (“PC”)) capable of responding to andexecuting instructions in a defined manner, a workstation, a notebookcomputer, a Personal Digital Assistant (“PDA”), a wireless phone, avehicle navigation system, a component, other equipment, or somecombination of these items that is capable of responding to andexecuting instructions.

In one implementation, the client devices 230 include one or moreinformation retrieval software applications (e.g., a browser, a mailapplication, an instant messaging client, an Internet service providerclient, a media player, a mobile location based services client, amobile mapping and/or navigation client, or routing application, orother integrated client) capable of receiving one or more data units.The information retrieval applications run on a general-purposeoperating system and a hardware platform that includes a general-purposeprocessor and specialized hardware for graphics, communications and/orother capabilities. In another implementation, the client devices 230includes a wireless telephone running a micro-browser application on areduced operating system with general purpose and specialized hardwarecapable of operating in mobile environments.

The client devices 230 may be configured to enable users to enterrequests for map or route information. The client devices 230 also maybe configured to enable users to enter condition information regardingfeatures of a map or route. The condition information may be sent to thehost 210. The client devices 230 may further be configured to receiveand render condition information and status information, along with mapor route information.

The communication networks 220 include hardware and/or software capableof enabling direct or indirect communications between the client devices230 and the host 210. As such, the communication networks 220 mayinclude a direct link between the client devices 230 and the host 210,or it may include one or more networks or subnetworks between them (notshown). Each network or subnetwork includes, for example, a wired orwireless data pathway capable of carrying and receiving data. Examplesof the delivery network include the Internet, the World Wide Web, a WideArea Network (“WAN”), a Local Area Network (“LAN”), analog or digitalwired and wireless telephone networks, radio, television, cable,satellite, and/or any other delivery mechanism for carrying data.

The host 210 and the information providers 240 includes ageneral-purpose computer having a central processor unit (CPU), andmemory/storage devices that store data and various programs such as anoperating system and one or more application programs. Other examples ofthe host 210 and the information providers 240 include a workstation, aserver, a special purpose device or component, a broadcast system, otherequipment, or some combination thereof capable of responding to andexecuting instructions in a defined manner.

The host 210 may include a host operated by an Online Service Providerthat provides mapping or routing services to subscribers. The host 210may be configured to provide navigation services. In one example, thehost 210 is configured to generate maps and route information regardinglocations, travel time, distance to the appointment location, and otherinformation. The host 210 may be configured to enable selection ofdifferent types of directions. For example, the host 210 may beconfigured to enable turn-by-turn voice guided navigation, mappingdirections, text directions, and/or “other” types of directions, such aswalking directions or public transportation directions. The host 210 maybe configured to send this information to the client devices 230 suchas, for example, a user's mobile device, the user's automobile, and/orthe user's computer.

The host 210 also may be configured to receive condition informationregarding features of a map or route. For example, the host 210 may beconfigured to receive condition information entered at the client device230 using a communications module 211 or condition information frominformation providers 240. The host 210 may be configured to store thecondition information in a condition information storage module 213 andmay determine, based on the condition information, a status of afeature. When determining a map or route information using the routegeneration module 212, the host 210 may access stored conditioninformation or statuses for features from the condition informationstorage module 213. Also, when delivering subsequent map or routeinformation generated by the route generation storage module 212, thehost 210 may include statuses of features included in the map or route.

The information providers 240 may include third party databasesaccessible by the host 210. For example, the information providers 240may include database information maintained or supplemented by a newsagency, transportation agency, other news gathering group, sensor data,or other information providers. The information providers 240 may besimilar configured to provide condition information as provided by theclient devices 230. Alternatively, the information providers 240 are notconfigured similarly to the client devices 230, and instead, provide rawdata. More specifically, in one implementation, a traffic database 241intermittently feeds specific information such as speed of traffic tothe host 241. The host 210 uses the traffic information to determinecondition information or statuses for features.

In one implementation, the client devices 230 alone may perform variousfunctions described above. For example, the client devices 230 mayperform the functions described above by referencing an internalnavigation application. In another implementation, the host 210 alonemay perform the functions described above. For example, the host 210 mayperform the functions described above by referencing a host navigationapplication. In yet another implementation, the client devices 230 andthe host 210 both may perform some or all of the functions describedabove. For example, a client device 230 may include a vehicle navigationsystem that performs routing, and a host 210 may deliver mappinginformation and condition information. Specifically, the client device230 may include mapping information for a given region when generating aroute. The host 210 may send the mapping information, such as thefeatures of an area, including condition information of one or morefeatures. The client device 230 may then, at the vehicle navigationsystem, calculate a route and status information using the receivedmapping information and condition information.

Referring to FIG. 3, the client device 231 may receive conditioninformation from a user and status information from the host 210. Theclient device 231 may be a specific exemplary implementation of theclient device 230 discussed with respect to FIG. 2. The host 210 may bea specific exemplary implementation of the host 210 discussed withrespect to FIG. 2.

The client device 231 may include a map display system 310, a globalpositioning system (GPS) 315, an electronic compass 320, and a dashboarddisplay device 325. The client device 231 also may include a peripheralstorage device 330 and may communicate with the host 210. The mapdisplay system 310, the GPS 315, the electronic compass 320, thedashboard display device 325, and the peripheral storage device 330 maybe physically located in a single system, such as, for example, in avehicle traveling a route.

The map display system 310 includes a condition/status informationprocessing module 340, a storage unit 345, a GPS interface 350, anelectronic compass interface 355, a dashboard display device interface360, an optional peripheral storage interface 365, a wirelesscommunication controller 370, and a system bus 375. The condition/statusinformation processing module 340 is a central processing unit (CPU)that processes executable instructions. The storage unit 345 storesexecutable instructions and data.

The dashboard display device 325 may include a screen for rendering mapor route information, status information, and condition information. Thedashboard display device 325 may include input controls configured toenable the user to input selection information and other information.For example, the dashboard display device 325 may include one or more ofbuttons, keys, a mouse, or a keyboard.

The wireless communication controller 370 is capable of exchangingwireless communications with the host 210 through a wirelesscommunications pathway. The wireless communication controller 370 onlymay be necessary when the map display system 310 includes a host. Thesystem bus 375 provides a series of parallel connections to allowcommunication between the condition/status information processing module340, the storage unit 345, the GPS interface 350, the electronic compassinterface 355, the dashboard display device interface 360, theperipheral storage interface 365, and the wireless communicationcontroller 370.

The condition/status information processing module 340 is configured toreceive input of condition information from a user, to send conditioninformation to the host 210, to receive status information from the host210, and to enable rendering of condition and status information. Inparticular, the condition/status information processing module 340 maycommunicate with the dashboard display device 325 through the dashboarddisplay device interface 360 to render input options for condition andstatus information.

In one implementation, the input option may be available icons that theuser may select. An icon may include a simple text string or iconindicating a condition. For example, an icon may include “trafficdeadlock” or may be in the shape of a stop sign. In anotherimplementation, a user may select a rendered feature and type-incondition information. The icons may be stored locally using theperipheral storage 330, on the host 210, or both. The icons may bestored as associated with specific coordinates or features of a map,with a route, or with steps or features within a route.

The condition/status information processing module 340 may sendcondition information received from the user to the host 210 using thewireless communication controller 370 and system bus 375. Sending inputcondition information may include sending an input text string, aselected tag, or an identifier corresponding to the selected tag alongwith a selected feature or an identifier corresponding to the selectedfeature.

Also, the condition/status information processing module 340 may receivestatus information from the host 210 using the wireless communicationcontroller 370 and system bus 375. The status information may bereceived along with or separate from receipt of map or routeinformation. For example, in one implementation, the status informationis received along with route or map information and updates to thestatus information are received afterwards. Receiving status informationmay include receiving a text string, a tag, or an identifiercorresponding to the tag along with a feature or an identifiercorresponding to the feature. In some implementations, the functionsperformed by the condition/status information processing module 340 maybe performed by a processor that also performs other functions, such asa processor associated with an on-board navigation guidance system.

Referring to FIG. 4, a process 400 for receiving condition informationmay be used, for example, with the devices and systems of FIGS. 2 and 3.The process 400 exemplifies two sources of condition informationreceived by the host 210—condition information received from input by auser of client device 231 and condition information received from atraffic database 241.

A first route including features is sent from a host 210 to a clientdevice 231 (410). The client device 231 receives the first route, andenables the user to enter condition information for one or more of thefeatures in the first route (420). The user may be enabled to entercondition information through use of the exemplary GUIs 500A-500C ofFIGS. 5A-5C. The content of the GUIs 500A-500C is exemplary only and mayinclude different or additional aspects. As shown in FIG. 5A, GUI 500Aincludes a map or route 510A and associated features 520A. The GUI 500Aalso includes an icon 525A detailing a status for a feature 525A, asource of the status 530A, reporting information 535A, and an option toinput condition information 540A.

The icon 525A may be the status or an indication of a status received bythe host 210. In some implementations, the icon 525A may correspond tocondition information input through the option to input conditioninformation 540A on the same client device 231 or on other clientdevices. As shown for icon 525A multiple icons may be displayed for asingle feature (e.g., an icon representing light traffic and anothericon representing heavy rain may both be displayed for the samefeature). The source of the status 530A indicates where the host 210received the information, and may specify, for example, users, newsreporting, traffic cameras, or other sources. The reporting information535A may specify the amount of users reporting, if applicable (e.g., atotal number, percent, or categorized amount as shown). The reportinginformation 535A also may specify other information corresponding to thereliability of the icon 525A, such as, for example, the time elapsedsince the host 210 last received condition information (or other data)used to generate the icon 525A. The option to 16 input conditioninformation 540A enables the user to specify condition information usedto update the status of a feature 520A.

The client device 231 then receives the condition information and sendsthe condition information to the host 210 (430). The client device mayreceive the condition information through user interaction with GUI 500Bof FIG. 5B or GUI 500C of 5C. For example, if the user clicks “add,” GUI500B may be shown enabling selection of the various available icons. Anicon corresponds to a specific type or category of condition informationand is used to enable ease of user input. GUI 500B includes a “Traffic”icon 552B, a “Weather” icon 554B, an “Other” icon 556B, and a “ManualEntry” icon 556. The listing of available icons is exemplary, and othertypes or categories may be used. Also, if the user clicks “update,” GUI500C may be shown enabling updating of a currently displayed icon. GUI500C includes a “Current Status” icon 562C which enables a user toupdate the condition information of the icon 525A displayed for afeature 525A. The available selections for the “Current Status” icon562C are specific to the type of icon 525A displayed (e.g., traffic,weather, etc.). The “New Status” icon 564C enables a user to addcondition information not related to a displayed icon 525A. The iconsmay include sub-options. For example, when selecting a “traffic jam”icon, the GUI 500B may prompt the user to enter a time of starting andending of the jam and whether the jam is reoccurring.

While FIGS. 5A-5C are described with respect to the process 400 of FIG.4, this context is only an example implementation. The GUIs 500A-500Cmay be, for example, rendered to a user at a computer outside of thecontext of requesting a route. More specifically, a user at a desktopcomputer may be shown the map 510A and, after interacting with the map510A, elements 520A-540A may also be shown to the user. Further, theuser at the desktop may receive reporting information indicative oftrends rather than reporting information indicative of currentconditions. For example, the icon 525A may reflect a time period orseverity of rush hour traffic rather than an indication of a currenttraffic level.

Moreover, the configuration of the features 520A-520C shown are alsoexemplary, and other or additional elements may be included in thefeatures 520A-520C. For example, reporting information 535A may includean indication of a window of time in which the information is pertinentor reliable. Moreover, the reporting information 535A may include atimestamp indicating the time of receipt of associated conditioninformation. As such, the window of time or the timestamp may be storedand used by the host similar to the storage and use of condition and/orstatus information as described in the process 400 of FIG. 4.

Receiving the condition information may trigger the host 210 to storethe received information, to use the received condition information torevise status, or both. Specifically, after receiving the conditioninformation, the host 210 may store the condition information asassociated with the one or more features (440). Storing the conditioninformation may include adding an entry in a condition informationstorage module 213 detailing the received condition information andparameters about its receipt, such as, for example, time sent, timereceived, tags received, and the authoring entity. Thereafter, the hostmay access data stored in the condition information storage module 231when determining a route or when sending a route to a client device.

After or alternative to storing the condition information (430), thehost 210 may revise a status by using the condition information todetermine whether to add, remove, or update a status (450). The statusmay be used to simplify and minimize processing where a large number ofusers send a large amount of condition information. In particular, theprocessing of determining whether to use condition information forrouting may be lessened by categorizing a number of indications as asingle status. For example, if a number of client devices sendindications of a road (i.e., a feature) ranging from “moderate traffic”to “stopped traffic” the host 210 may determine a status of the road as“heavy traffic,” and store the status as associated with the road instep 450. In the above techniques, the system may reference the storedstatus instead of the stored condition information, for a given feature.Various logic may be used to determine whether received conditioninformation adds, updates, or removes a status. For example, based onstatus generation rules, a status may be added, updated, or removed if athreshold number of same or similar condition information is receivedwithin a threshold amount of time, if a threshold percent of same orsimilar indications are sent from client devices who have been sent mapor route information including the relevant features within a thresholdof time, if the indications are sent from particular users or aparticular category of users, or through use of other considerations.

Revising a status also may include generalizing, weighing, or averagingcondition information received from one or more users. For example, inone implementation, the host 210 uses a weighted average formula torevise status, where more recently received condition information isgiven greater weight in the revision. Also, in one implementation, ifthe host 210 determines to update an existing status, the host 210 sendsupdates to client devices recently sent the previous status or a routeincluding the feature corresponding to the previous status. Differentimplementations may determine or revise statuses at different times.Specifically, the host may 210 access condition information whendetermining a route (see FIGS. 8A and 9A) such as, for example, toenable user of user-specific status generation rules, and may not relyupon revising statuses at the time condition information is received. Inother implementations, the host 210 may access statuses when determininga route (see FIGS. 8B and 9B), and thus, may not rely upon storingcondition information as the condition information is received, butrather, may rely upon revising statuses as the condition information isreceived.

The traffic database 241 sends further condition information of the oneor more features to the host 210 (460). The further conditioninformation may be similar in format or content to the conditioninformation provided by the client device 231. Alternatively, thefurther condition information may be data, such as the speed of traffic.After receiving the further condition information, the host 210 maystore the further condition information as associated with the one ormore features (470). After or as an alternative to storing the furthercondition information (470), the host 210 may revise a status by usingthe further condition information to determine whether to add, remove,or update a status (480). The steps taken by the host 210 after receiptof condition information by the client device 231 (440 and 450) may bysimilar to the steps taken by the host 210 after receipt of furthercondition information by the traffic database 241 (470 and 480). Inimplementations where the traffic database 241 sends data dissimilar tothe condition information sent by the client device 231, the host 210may take an additional step of analyzing the data to determineappropriate condition information. For example, the host may determinethat data showing traffic speed for a feature is 0 miles per hourrequires condition information of “dead-locked” traffic for the feature.

Referring to FIG. 6, a process 600 for enabling a user to perceivestatus information exemplifies a situation where the host 210 providesstatus information to a client device along with a requested route. Theprocess 600 may occur after part or all of the operations of process 400shown with respect to FIG. 4 are carried out. Further, the process 600may be used with the devices and systems of FIGS. 2 and 3.

The process 600 begins when the client device 232 sends a request for aroute to the host 210 (610). The host 210 receives the request (620),and in response, accesses stored condition information or statuses offeatures and generates the route (630). The host 210 may access thecondition information stored with respect to steps 440 and 470 and/orthe statuses with respect to steps 450 and 480. As described in furtherdetail in FIGS. 9A and 9B, the condition information or statuses may beaccessed prior to generating the route and may effect the determinationof the route.

In various implementations, the system considers the conditioninformation or statuses when generating a route as illustrated by FIGS.9A and 9B. These implementations enable flexibility in that the initialrouting is affected by the stored condition information or statuses andmay take into account route generation rules as discussed with respectto FIG. 9A. For example, if accessed condition information and/or statusfor a feature corresponds to “stopped traffic”, the host 210 may, basedon the accessed condition information or status, determine a route thatdoes not include the feature for some or all of the client devices.Alternatively, the condition information or statuses may be accessedafter generating the route as illustrated by FIGS. 8A and 8B. Theseimplementations enable simplicity in processing in that routing caninitially be calculated without consideration of condition informationand statuses, and only condition information and features associatedwith a route need be considered. For example, after generating arequested route, the host 210 may access condition information or astatus corresponding to features in a route, and thus, consider “stoppedtraffic” for a feature determined to be in a route. The system mayautomatically create a revised route that does not include the featurehaving a status of “stopped traffic.” Additionally or alternatively, thesystem may consider user or client specific options to determine whetherto create a new route and/or may query the user as to whether he/shewishes to create new route that does not include the feature.

The host 210 determines whether a status of one or more features shouldbe sent with the route (640). In one implementation, determining whethera status of one or more features should be sent consists of determiningwhether a status is available for the one or more features. In otherimplementations, determining whether a status of one or more featuresshould be sent includes other considerations, such as, selection ofuser-specific options. In particular, users or client devices may setuser or client specific options including when, whether, or how to sendstatuses with routes. For example, a user may specify not to send statusrelated to weather but to send status related to traffic congestion.

If the host 210 determines a status should not be sent with the route,the host 210 sends the route to the client device 232 (650), and theclient device 232 enables the user to perceive the route (660). If thehost 210 determines a status should be sent with the route, the host 210sends the route and the status of the one or more features to the clientdevice 232 (670), and the client device 232 enables the user to perceivethe route and the status of the one or more features (680).

Enabling the user to perceive the status of the one more features mayinclude enabling additional features as shown in the exemplary GUIs 700Aof FIG. 7A and 700B of FIG. 7B. Referring to the GUI 700A of FIG. 7A,the user may request a route be recalculated based on the icon 725Acorresponding to the received status in step 680. The rerouting option730A may detail specific information regarding the reporting of thestatus information, and may enable a user to set future preferenceswhich may automatically be taken into account in the processing of steps630 and 640. Referring to the GUI 700B of FIG. 7B, the client device 232may enable a user to interact with features on a map 740B to view anicon 725B corresponding to the status of a feature or to update thestatus through inputting condition information for the feature. Forexample, a user may be enabled to click on a location or a features onthe rendered map 740A, and as a result of the click, an icon list 750Bcorresponding to a feature is rendered for user input of conditioninformation.

While FIGS. 7A and 7B are described with respect to the process 600 ofFIG. 6, this context is only an example implementation. The GUIs 600Aand 600B may be, for example, rendered to a user at a computer outsideof the context of requesting a route. For example, a user at a desktopmay be rendered the map 740B. After clicking on a feature of the map740B, the icon list 750B may be rendered. The user may select predictiveinformation, such as an icon relating to rush hour times, and the usermay then enter condition information specifying the prediction as towhen rush hour occurs for the selected feature. The conditioninformation specifying the prediction as to when rush hour occurs forthe selected feature may result in status information for features beingrendered to users of desktop computers as well as to users traversingroutes as described with processes 400 and 600 of FIGS. 4 and 6.

Referring to FIGS. 8A-8B, the flow charts illustrate examples ofsub-processes 800A and 800B which access condition information orstatuses after determining features in a route. More specifically, thesub-processes 800A and 800B exemplifies a situation where the host 210determines features to be included in the route, and based on thedetermined features, selectively accesses the status or conditioninformation of the determined features. The sub-processes 800A and 800Bare two implementations of the process 600 described with respect toFIG. 6.

As shown, sub-process 800A accesses statuses whereas sub-process 800Baccesses condition information for a determined route. The method ofaccessing status information as illustrated by FIG. 8A may enablegreater efficiency as a single status may be calculated for all users.The single status may be accessed when necessary (e.g., when the featurecorresponding to the status is determined to be in a mute). In contrast,the method of accessing condition information as illustrated in FIG. 8Bmay enable greater flexibility in that statuses may be selectivelydetermined for each user. For example, if a user specifies that theywish to only have condition information from a list of buddies to beconsidered when determining their status (e.g., as a user-specificstatus generation rule), the system can access only the stored conditioninformation from the specified users for the features determined to bein a route.

Referring to FIG. 8A, the sub-process begins after the host 210 receivesthe request for a route (620). The host 210 determines the features tobe included in the route (825A). After determining the features to beincluded, the host 210 determines whether any stored statuses areavailable for the features to be included in the route (830A). If thehost 210 determines that no statuses are available for the features tobe included in the route, the host 210 sends the route to the clientdevice 232 (650). If the host 210 determines that stored statuses areavailable for the features to be included in the route, the host 210determines whether a status of one or more features should be sent withthe route (840A). As discussed above with respect to FIG. 6, determiningwhether a status of one or more features should be sent may consist ofdetermining whether a status is available or may include variousconsiderations, such as, for example, whether a user has selectedoptions specifying that they do not wish to be sent. If the host 210determines a status should not be sent with the route, the host 210sends the route to the client device 232 (650). If the host 210determines a status should be sent with the route, the host 210 sendsthe route and the status of the one or more features to the clientdevice 232 (670).

Referring to FIG. 8B, the sub-process begins after the host 210 receivesthe request for a route (620). The host 210 determines the features tobe included in the route (825B). After determining the features to beincluded, the host 210 determines whether any condition information isavailable for the features to be included in the route (830B). If thehost 210 determines that no condition information is available for thefeatures to be included in the route, the host 210 sends the route tothe client device 232 (650). If the host 210 determines that conditioninformation is available for the features to be included in the route,the host then determines whether a status should be generated and sentalong with the second route (840B). As discussed above, determiningwhether the status should be generated or sent may include considerationof status generation rules or user selected options. If the host 210determines that the status should not be generated or sent, the host 210sends the route to the client device 232 (650). If the host determinesthat the status should be generated and sent, so the host 210 then sendsthe route and the status of the one or more features to the clientdevice 232 (670).

Referring to FIGS. 9A-9B, the flow charts illustrate examples ofsub-processes 900A and 900B which access condition information orstatuses before determining features in a route. More specifically, thesub-processes 900A and 900B exemplifies a situation where the host 210considers available condition information or status when determinewhether features are to be included in a route. The sub-processes 900Aand 900B are two implementations of the process 600 described withrespect to FIG. 6.

Referring to FIG. 9A, the sub-process 900A begins after the host 210receives the request for a route (620). The host 210 accesses storedstatus of one or more elements to be considered for the route (930A),and based at least in part on the statuses, determines the route (935A).Accessing the stored status may include accessing a stored indication ofthe status when processing routing algorithms. In one implementation,accessing the stored status includes accessing a stored status databaseand global or user-specific route generation rules. For example, in oneimplementation employing cost-based routing, accessing the storedstatuses may include accessing indications of routing cost correspondingto statuses and a cost-altering route generation rule. Specifically, thecost-altering route generation rule specifies that a cost associatedwith traversing a feature may be increased if a feature corresponds tocertain stored statuses. For example, for a status of “heavy traffic,”the cost-altering route generation rule may double the cost oftraversal, thus weighing in the cost algorithm against featureselection. Based on the accessed statuses and the determined mute, thehost 210 determines whether a status of one or more features should besent with the route (940A). If the host 210 determines a status shouldnot be sent with the route, the host 210 sends the route to the clientdevice 232 (650). If the host 210 determines a status should be sentwith the route, the host 210 sends the route and the status of the oneor more features to the client device 232 (670).

Referring to FIG. 9B, the sub-process 900B begins after the host 210receives the request for a route (620). The host 210 accesses storedcondition information for one or more features to be considered for theroute (930B), and based at least in part on the condition information,determines the route (935B). Accessing the stored condition informationmay include accessing and considering cost information as discussedabove with respect to FIG. 9A. Based on the accessed conditioninformation, the host 210 then determines whether a status should begenerated and sent along with the route (940B). If the host 210determines a status should not be sent with the route, the host 210sends the route to the client device 232 (650). If the host 210determines a status should be sent with the route, the host 210 sendsthe route and the status of the one or more features to the clientdevice 232 (670).

A number of embodiments have been described. Nevertheless, it will beunderstood that various modifications may be made without departing fromthe spirit and scope of the application.

1.-35. (canceled)
 36. A computer-implemented method, the methodcomprising the following operations performed by one or more processors:providing, to a first device of a first user, instructions to display afirst route; receiving, from the first device, input by the first user,the input including an observed condition of at least one featureassociated with the first route; determining, based on the input andcondition information received from sources other than the first user, astatus of the at least one feature associated with the first route;storing, in a memory device, the determined status of the at least onefeature; receiving, from a second device of a second user, a request fora second route, the second route including a plurality of featuresincluding the at least one feature associated with the first route;accessing, from the memory device, the determined status of the at leastone feature; and providing, to the second device, information about thesecond route and the status of the at least one feature.
 37. The methodof claim 36, wherein at least one of the first and second devices is amobile device.
 38. The method of claim 36, further comprisingdetermining the second route based at least in part on the input and thecondition information received from sources other than the first user.39. The method of claim 36, wherein the observed condition includes atleast one of traffic, traffic movement, congestion or delay, weather, adetour, a road blockage, or a speed trap.
 40. The method of claim 36,further comprising: determining whether the first user is on a buddylist of the second user, incorporating, based on a determination thatthe first user is on the buddy list, the input by the first user intothe information provided to the second device.
 41. The method of claim36, wherein the first user provides the input by selecting an iconassociated with the observed condition.
 42. The method of claim 36,wherein the second device indicates the status of the at least onefeature by displaying an icon.
 43. A system, comprising: one or morememory devices that store instructions; a network communication deviceconfigured to communicate with mobile devices over a network; and one ormore processors configured to execute the instructions to: provide, viathe network communication device, instructions to a first mobile deviceto display a first route; receiving, via the network communicationdevice from the first mobile device, input by the first user, the inputincluding an observed condition of at least one feature associated withthe first route; determine, based on the input and condition informationreceived from sources other than the first user, a status of the atleast one feature associated with the first route; store, in the one ormore memory devices, the determined status of the at least one feature;receive, via the network communication device from a second mobiledevice of a second user, a request for a second route, the second routeincluding a plurality of features including the at least one featureassociated with the first route; access, from the one or more memorydevices, the determined status of the at least one feature; and provide,via the network communication device to the second mobile device,information about the second route and the status of the at least onefeature.
 44. The system of claim 43, wherein the one or more processorsare further configured to execute the instructions to determine thesecond route based at least in part on the input and the conditioninformation received from sources other than the first user.
 45. Thesystem of claim 43, wherein the observed condition includes at least oneof traffic, traffic movement, congestion or delay, weather, a detour, aroad blockage, or a speed trap.
 46. The system of claim 43, wherein theone or more processors are further configured to execute theinstructions to: determine whether the first user is on a buddy list ofthe second user, incorporate, based on a determination that the firstuser is on the buddy list, the input by the first user into theinformation provided to the second mobile device.
 47. The system ofclaim 43, wherein the first user provides the input by selecting an iconassociated with the observed condition.
 48. The system of claim 43,wherein the second mobile device indicates the status of the at leastone feature by displaying an icon.
 49. A computer-implemented method,comprising the following operations performed by one or more processors:displaying, on a device of a user, a travel route; receiving, at thedevice, input of the user reflecting an observed condition of at leastone feature associated with the travel route; and transmitting, to ahost system, an indication of the input of the user, the host systemdetermining a status of the at least one feature of the route based onthe input and condition information received from other sources.
 50. Themethod of claim 49, wherein the device is a mobile device.
 51. Themethod of claim 49, further comprising executing a navigationapplication stored on the device, wherein the displaying, receiving, andtransmitting are facilitated by the navigation application.
 52. Themethod of claim 49, wherein the observed condition includes one or moreof traffic, traffic movement, congestion or delay, weather, a detour, aroad blockage, or a speed trap.
 53. The method of claim 49, whereinreceiving the input includes: displaying an icon for the observedcondition displayed on the device; and receiving a selection of theicon.
 54. A mobile device comprising: a display device; a user inputdevice; one or more memory devices that store instructions; a networkcommunication device for communicating over a network; and at least oneprocessor configured to execute the instructions to: present, on thedisplay device, a route; receiving, via the user input device, inputreflecting an observed condition of at least one feature associated withthe route; transmitting, via the network communication to a host system,an indication of the input, the host system determining a status of theat least one feature of the route based on the input and conditioninformation received from other sources.
 55. The mobile device of claim54, wherein the instructions comprise a navigation application.
 56. Themobile device of claim 54, wherein the observed condition includes atleast one of traffic, traffic movement, congestion or delay, weather, adetour, a road blockage, or a speed trap.
 57. The mobile device of claim54, wherein the one or more processors are further configured to executethe instructions to: present, on the display device, an icon for theobserved condition; and receive, via the user input device, a selectionof the icon.